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(57) A system for secure multicast including a plu- 
rality of participants (103) that can send and receive 
multicast messages is disclosed. A traffic distribution 
component (102) is coupled to the participating entities, 
where the traffic distribution component supports multi- 
ple receiver communication. A participant key manage- 
ment component (109) operates within each participant 



entity (101) where the participant key management 
component uses a first key (110) that is shared with all 
the other participants, and a second key (107) that is 
shared with a sub group of the participants. A group key 
management component (108) is implemented using a 
flat data structure having a size that is logarithmically 
proportional to the number of participants. 
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Description 

BACKGROUND OF THE INVEhfnON 

1. Related Applications. 

[00011 This Is a continuation-in-part of U.S. Patent Application Serial No. 09/009.475 filed January 20. 1998 tilled 
■Efficient Secure Multicasting with Global Knowledge" invented by the inventors of this application and assigned to 
the assignee of the present invention. The entire specification of U.S. Patent Application Serial No. 09/009.475 is 
Incorporated herein by reference. 

2. Reld of the Invention. 

[0002] TTie present invention relates, in general, to group data communications, and. more particularly, to secure 
multi-destination communications over an unsecured communication channel. 

3. Relevant Background. 

[00031 Distributed applications such as multimedia conferencing, computer-supported collaborative work, distributed 
computing, and remote consultation and diagnosis systems for medical applications depend on efficient infomiation 
exchange among multiple participants, iwlulti-destination communication and data exchange over a public network are 
essential for such applications. TTiis type of communication is referred to generally herein as -multicasf. Some appli- 
cations generally referred to herein as "broadcasting applcations'. are characterized by a small number of sending 
parties 'and a large dynamically changing group of receiving parties. Other applications referred to herein as confer- 
encing applications' involve a large number of sending and receiving participants. 

[00041 When a group of people want to communicate over a public netvrork such as the Internet in a conference, 
every message sent out by one of the participants is received by all other participants. The mechanism used to do this 
communication is called multicast. Any Internet subscriber or user with access to a public network may subscribe to a 
multicast communication group and will subsequently receive all messages sent to this group. Addrtionally, any Internet 
subscriber will be able to send messages to the whole group. 

[00051 fwlulticast is rapidly becoming an important mode of communication as well as an effective platform for building 
qroup-oriented services. However, to be used for secure or trusted communication, existing multicast techniques must 
be supplemented by tools tor protecting (i.e. encrypting and authenticating) traffic, controlling participation, and re- 
stricting access from unauthorized users. 

[0006] A need for secure electronic information exchange over insecure public networks is increasingly apparent. 
As compared to conventional unicast. (i.e.. point-to-point), multicast is more susceptible to attack. ((Multicast transmis- 
sions present substantially more opportunities for interception of the traffic due to the fact that the message is potentially 
distributed over a large portion of the network. When an attack occurs, a large number of multicast participants are 
affected Further, since multicast addresses are often well known, it becomes easier for an attacker to target an attack 
IVloreover, multicast typically involves a large number of authorized users which can make it easier for a 9^"? oi 
colluding members (or a single attacker posing as a group of legitimate users) to attempt attacks in Pfrallel^ile 
secure unicast communications are well understood, prior attempts at secure multicast communication have difficulty 
in scaling to large groups and handling groups with highly dynamic membership. 

[0007] To help achieve secure electronic information exchange, any network security protocol should allow author- 
ized participants to communicate securely over an insecure network under conditions where an attacker is assumed 
to be able to read, insert, modify, and delete raw communications. Typically, this protocol is achieved by creating a 
security association between the authorized participants through authenlcatwn and key exchange. The securrty as- 
sociation defines a set of keying material shared only by the authorized participants that can be used for a vanety of 
security objectives such as authentication, confidentiality, and integrity verification. 

[COOS] 1 n a multicast scenario, the security association between participants must be dynamic to support membership 
changes A secure multicast communication group must ensure that participants are only allowed to participate during 
periods when they are authorized. A participant may be authorized to participate in the secu re multicast at some periods 
of time and not authorized to participate during other periods. For example, in a pay-per-view program access a receiver 
is onV authorized for the time periods for which they have paid. The security association and the group keying material 
it defines must be changed each time a participant joins or leaves the multicast group. This change is necessary to 
ensure that a joining participant is not able to understand data that was previous^ multicast and the leaving entity is 
not able to continue to understand data multicast after its authorization expires. The management and distribution of 
dynamic security associations and keying material is a fundamental difficulty in a secure multicast protocol. 
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[0009] Practical communication systems must provide reasonable effic.ency over the "^^/^ J^f ^"^^ 
rnean that the steps taken to ensure secure communication do not add an ordinate amount o1 o^^^head traffic tha 
^Turni bandwidth without transferring 'payload- information (e.g.. application-level data) between Part«:'pan 
^ ores^wrZe all communicatk^ networks will have some bandw^h limitation -^^^ ^^^^^l^^ZZ 
Indent communication systems. Hence, it is desirable that the security procedures requ.re ^^^"^^^^^ 
between participants to perfom, key management. In fact, in some scenarios such as ° J^J''^^!^'^' 

ttTe is only a c^e-way channel available in which case the need for minimal participant commui^«at.on « f^^^^^ 
S o Efficiency al^ means that the steps taken to ensure secure communicatbn do -t^^^ ^ "^^^^^^^ 
Lputational and data structure burden on the participants. Key management and ^^-'^^^^'^^^ ^'^^^ 

participants to perform some additional computation to retrieve a secure 
So require theparticipants to implement data structures (i.e., tables, key storage areas, and the hke) that may have 

derable sizklt otten occurs that the number, ste and/or complexity of these ^^^P'^^'^^^fl'^ ^J^^^^^^^^^ 
Sease as the number of participants in the multicast communicatton group increases. In many cases. *e complexrty 
i^crses m^^^^^^^^^^^ than'the number of participants making the secur^ method ""--^^^ ';;XhI SeTd 
putational and data structure costs. Increasing complexity results in poorer perfomiance and/or higher hardware and 

S'^rihtv^^^^^^^^ over the networ^.l. participants in the group need to share a 

Sri Jor^^l e key intormatton). The manner of how this secret infomiation is shared and maintained during 
grip Ja Hof tie present inventton. Prior applications may continuous^ ^t^.^onTc • 
^necS^s bemeen a sender and all receivers to update security associations and exchange key '"^"^'O^^Such 
^ nuoXSiired unicast connections are not practical for large sroupsJFor a ^^^^J^'';'^^^^':^^^ 
^» opnflrat^or a messaoe has to be processed by intermediate hops which is not efficient. Given a la ge group 
lT^^ZZ aZ^:>^:s.. .eav^ and join an'd where the actual key has '^e^-f ^^^^^^^^^ 
join to Zhieve privacy, computing resources may be insufficient ,f extensive computatK», (e.g.. such as associated 

fo^ internet protocols (SunScreen™ SKIP. (SunScreen is a trademari< of Sun Microsystems. Inc.). SKIP is a P^^^^^^ 
certneiaS^y-m^^^ scheme which provides group key-management for Internet protocols. Pnor rnu - 
mpSmen J;ici,s of SKIP create a single mult«:ast group and do not handle automat, ^^y-^^^^^^^^^ 
iSnts join and leave the group. Designed to be applfcatk,n independent. SKIP can be plugged into P Secunty 
PrSS of IPV6. Usfng certified Diffie/Hellman keys. SKIP obVBtes the need for real =«f ""f f,Jf "^^'^ 

hX'S session state in^m«tion that can be discarded and reproduced if nece^n^ J^nlac^nmae 
DS^mmunicationsbetween two participating ends in order to acquireand update traffic keys. Th««^ 

o SK^pTat "rparticularly suited to connectkxiless datagram protocols such as the Internet protocol. In the SKIP 
sX Tai paSi^nt L the capabilrty to construct a shared secret (i.e., information needed for symmetric en- 
c^SS only^ knowledge of the other participants' public key combined with its own pnvate key 
fooiT i^ttS^sa^rS proto^ls exhibit seveial types of scalability failures. A firs, type of 
S^^o idatSe actiondone membertoaffect the entiregroup. T^^ 

S^n^t deal with the group as a whole and instead, must consider the conflicting demands of ^''^"'^^^S.^^ 
Sua! baSs Thte JequLs point-to-point or unicast communication with each participant which reduces efRcien^ 
al more Snts ar^added' A need exists for a multicast system that so^^es these and other sca^b.lity 

^Xr^AZ M^ Wea of a single flat secure mutttoast group. Instead, lolus substitutes the notion of a s^ure 
HL^K^c^Teelhe secure distributton tree comprises a number of smaller secure mufficast subgroups arranged in 
a hi to crelJe a S:?-!, secure mu«u:rst group. Because each subgroup managed relajK^hj .ndepen^^ 
ent^me To us framework is scalable. Each subgroup in the secure distribution tree has its own mult cast group and 
Sl aea S an^^aged using any suitable multicast routing protocol. One feature of the lolus system « tha he e 
J o gS ^oup k7or secret information that is shared among all of the subgroups. Hence, 'o'us r^".^ tr st n 
hi'parfi such'as'routers or other network components. Thus, when a member ,om 

oSl subarouD However because there is no global secret infomiation shared among all of the participants, re keying 
IrStttS^FlIiTSta sent in the framev^rk must be re-keyed each time it gets into a different subgroup thereby 

eraSvely compute a common session key. In a first example the participants are log«^ny ^^^9^ ^ ""9 ^^^^J 
toy vSue to the p<»ver of rts own exponent and fon«ards the result to the next participant After n-1 rounds every 
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participant holds the same key. This protocol involves high latency, is computationally burdensome for large groups. 

and is primarily suitable for static key distribution. . . ^ ,„ th» rnimd Pach 

S)16] AmJe efficient protocol uses broadcast messages and executes .nonly three rounds. In me ^ 

Santselectsarandomexponentr,computesavaluezpaH{modp).andbroadcastsz,Seco^^^ 

rtte =.r,H hmarira.5t.; Y- (2 Jz, K/fHod p) In the last round, each participant can compute the conference key 
r X ? ^ f^S^^S^. key : identic^ for all participants. Mhough this protocol is rough V 

S";ist as RSA and as secure asihe Diffie-Hellman problem, Is difficult to deploy in a dynamic group. All members 
S^^eto keep transient states for possible changes in the group membership, othen^se each lo.n - 'ea^^^^ 
SiLered as a new group and all three rounds need to be redone. Also, the cooperation of all partcpants, mvolvng 

'i;^TlTS.T^^'^^^T^^^^ to distribute sessk^n keys in dynamic groups where a 'group man- 

LTeVltih^op rfo^^^^^^ 

a sesSey in highly dynarn^ groups, the solution d^^ 

K'^'Anel^'Lainsforagroupdatacommunicatk.smethodand^^^^^^ 
communications over an unsecured communicatran channel efficiently. 

SUIjIMARY OF THE INVENTION 

r00191 Briefly stated, the present invention involves a system for secure muHbast including a plurality °' rt^^'P^"*^ 
Stlser^dand/orreceivemulticastmessages.Atrafficdistri^ 

"me traffic distribution component supports receivers at muttiple destinatk^s. ^ ^J^^f J -Tiro l^^ 
nent uses a first key that is shared with all of the other participants, and a number of second '^'''^l^^^ 'T^ll 
^ared with a set of subgroups where the first and second keys are stored and maintained in a group key database. 
The arouD key database "is implemented in a non-hierarchical, flat fashion. ^. , ^ foehinn 

S Tn a first implementafion. the group key management component is -P'^-^^^. ^ .^^^l^^trS" 
among a plurality of the participants such that the group key database is implemented in a distributed d^ta structure^ 
ra^'c^ndimp^mentatSn.thegroup key management comp^^^^ 

c^^nent has global knowledge of shared key information without knowledge of which part«ipants share that key 

information. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0021] 

FIG. 1a and FIG. 1b illustrates in block diagram term exemplary embodiments of a secure multicast mechanism 
in accordance with the present invention; 

FIG. 2 shows in block dagram form exemplary component parts of a secure multicast system in accordance with 
the present invention; 

FIG. 3 shows a key database in accordance with the present invention; 
FIG. 4 shows an example entry from the database of FIG. 3 in greater detail; 

FIG. 5 - FIG. 7 show in btock diagram fomi a key merging feature in accordance with the present invention; and 

FIG. 8 illustrates an exemplary data packet used for communicating information in accordance with the present 
invention. 

DETAILED DESCRIPTION OF THE PREF PRBgP EMBODIMENTS 

[00221 Proposals for multicast security that have been published to date are corriplex. often require trust in networic 
Snents^are inefficient. The present invention involves a number of ^P^^^^^ ^^^^^^^ 
in foVexamole Internet protocol (IP) multfcast as well as providing group-wide prwacy and authentttation. The present 
TniS^ empk>yed to eicientty secure multiparty applications where members of highly dynamic groups 

?S"Cr-ntC2"is described in tern, of a secure mulf^ast system and protocol but is more general. 
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viewed as a group communications security protocol. The system and method in accordance wrth f'^f"' ^^f 
provide several useful features including prt>«cy of wideVtransmmed messages, the abilitytousGuntrust^ 

network components, and full exploitation of multicast features. In accordance with the present '"^ent.on key rnan- 
aqement is provided with minimal computation and reduced storage requirements among the partcpants in a multicast 
communication group. The present invention logically organizes participants in a multk:ast '°" SJ^"'" 

a plurality ol smaller virtual subgroups defined by the keying material they share with other participants. The present 
invention does not require the explicit assignment of partteipant identifications which simplifies synchronization o^., 
ensuring that each sending entity uses a consistent group-wide reference for each participant) m an environment havmg 
multiple sending participants. AddHionally. a global and implicit way to define participant IDs 
to inittete a leave operation without concern as to what ID other members know the leaving party by Also, the system 
in accordance with the present invention prevents participants from reading future or past traffic that is outside ol the 

[(Sa^^A J^Xencing or group collaboration scenario is characterized by a large. dynamtealV ^'^^^"SS^I 
Urtfcipan. entities where each participant may be both a sender and a rece^^er. Rented ^ ^^P^ '^P'^^^^/^^^^^ 
Nto 09/009.475 is directed at solutions particular^r useful h a broadcast scenario where only a fewo '^e partici^nts 
are senders and each participant heW global knowledge in the fom, of keying infomiation. In the related apPjca« on 
each participant has knowledge of group membership, and so each- participant includes s^°^9^^.sP^<=« ™9 
keying infom^tion shared with group members. For example, in a situation with a number N participants and each 
partk=lan,isidentiRedbyaW-bittongnetwort.address.theparen.applicationusesahierarchicalc^^^^^^ 
Ttotal^ (2.N)-1 entries in the group key manager. In contrast, the present invention uses a flat structure that 
reduces storage requirements to only W+1 entries stored in each participant in a first embodiment and 2.Wh.1 er^^ies 
In a centraliz^ database in a second embodiment. By using a flat key data stmcture. the data structure s^ze « l<^a- 
rithmfcally proportional to the number of participants as compared to hierarchkal key data structures that have a size 
linearly proportksnal to the number of participants. ^ „ . . , j- 

[002q Alrst implementation of the present invention, referred to herein as a 'distributed flat' "^^^^'^''^^^ 
particularly useful in a conferencing or group collaboration scenario. In this first implementation the flat <lata ^truc^^ J 
isdistributed across multiple participants. This implementation is immune to setup implosion because adm.ss«n coritrol 
responsibilities are distributed throughout the multicast group. Setup imptosion occurs, for examp e. « f "'^''^^f 
access control entity must manage join and leave informatton from each of the participants As '^^f °' 
pants increases, the likelihood of receiving more messages than the centralteed access control entity can handle (i.e 
implosion) increases. Access control and key management in accordance with the present invention are pertomied by 

the participants independently. r^^u^rxrv 
[0026] Additionally, the distributed system is more resilient against failures. The loss of some members or nehvorK 
inks does not automatically result in the failure of the whole group. In hierarchical approaches, '<»s'"g «""y 
implementing the group key manager function is fatal. In the distributed flat ^plementation °» P^^^^"^^^^^^ 
changeover orhandoff of control of intomiation held byamissing participant IS done automa^callylnacemra^^^^^^ 

implementation of the present invention, described below, a new participant can be elected to ^plement the group 
key manager function at the cost of some added complexity. 

[00271 Asecondimplementation,referredtohereinas-centralizedflatMsparticularlyusefulinthebroadcaslscer«n^ 
where data traffic is substantially unidirectional. The second implementation uses a centralized entity to '"iptement the 
flat data structure. The centralize fiat implementation reduces the data structure size to 2W+1 entries ^eldjn a cen 
traiized entity and reduces or eliminates any need for participants to communicate key control information with eacn 
other While the centralized approach results in a central point of failure and is not immune to setup implosion, it provides 
many of the advantages and functionality of the first implementation described above. 

[0028] Although each implementation of the present invention is described in temis of a scenario in which it has 
greatest utility, it is to be expressly understood that either implementation can be "^efully. although perhap^not^ opti- 
mally adapted for use in either broadcast or conferencing scenarios with appropriate modiflcations. Also. al*o"gh the 
implementations are described in temis of a W-bit long network address for each participant. 
each participant can be identified with a W-symbol wide ID where each symbol composes multiple bits. TJ^^ "^P^ 
menta^on is preferable in many applicatfons because it altows each symbol to take on multiple (in contrast with on^ 

Sffl '"The secure multicast architecture in accordance with the present invention is usefully de«r|bed as a plurali^ 
L interactbig components as shown in FIG la and FIG. lb. The components in FIG. 1a illustrates the d.s "buted flat 
implementatton in a group conferencing scenario whereas FIG. 1b illustrates the centraUze '^.'^P^";^^" J^J"''^^ 
numbered components in FIG. la and FIG. 1 b serve substantially equivalent purposes and provide substantially equn/- 

SorFlS^I a illustrates a scenario in whfch each participant 1 01 may be a sender andtor a receh^er by communU 
eating data packets over multicast data connection 102 to data multicast group 103. in a group conferencing scenano. 
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senders and receivers may not be distinguishable. Any participant 101 is free to send data over multicast data con- 
nection 102 where the data is encrypted using secret infonnation shared by all the participants 101 . In a group collab- 
oration environment, for example, each participant 101 holds both sender and receiver roles at the same time. 
[00311 In the group collaboration scenario illustrated in FIG. 1 an admissbn control component 110. is contacted via 
a one shot control connection 104 by each new participant 101 to join the group. Control connection 104 can be 
implemented, for example using a secure unicast connection or an out-of-band channel when there is not a return 

moazf In the implementation shown in FIG. 1 a. admission control component 11 0 is replicated several times in several 
participants 101 In practice it is likely that each participant 1 01 includes an admission control component 110. although 
in a particular instance some admission control components 110 will be active and others will be dormant when not 

Group key management component 108 accepts participants 101 that are admitted by an admission control 
component 110 and receive their keying material. Optionally, any admission control component 110 may also initiate 
forced leave of any participant 101 unilaterally without being contacted. 

[0034] Control connection 104 comprises, for example, a conventional unicast connectksn that is established ana 
taken down as needed during admisswn control operations. This unicast connection only exists once for each partic- 
ipant 101 and can be dissolved after the participant 101 receives its sef up infomriation. In this manner the relatively 
significant overhead created by setting up a new participant 101 is only performed when necessary, greatly ""proving 
the efficiency of the system in accordance with the present invention. This unicast connection may also be handled 
20 using out-of-band methods. .inQo„^ 
[0035] The admission control component 110 communicates with the group key management component 108 and 
infomis itof joinsand leaves. Group management component 108 manages join and leave operations, and establishes 
and generates messages to have key manager components 109 perform necessary key changes (described herein- 

[OMS] Key control group 107 is a virtual subgroup of participants defined by shared keying information and linked 
by any multicast, broadcast, or anycast channel delivering packets from group management components 108 to key 
manager components 109 of at least the intended participants 101 . Traffic in key control group 107 comprises packets 
containing new keying material which needs to be distributed to key management components 109. The keying infor- 
mation that defines key control group 107 is held in the flat data structure or key database in accordance wrth he 
present invention. In the implementation shown in FIG. 1a. the physical instance of this key database is distnbuted 
among a plurality of participants 101. 

[0037] In the implementation shown in FIG. lb, admission control component 120 is implemented in a centralEed 
entity. Optionally, admission control 110 and group key manager 118 can be united in a single entity with a sending 
participant 121 to establish the single sender for a group. Alternatively, these components can be implemented in 
separate entities. In this implementation, only the centralized admission control component 120 can perform access 
control and communicates with group key management component 118 to informs it of joins and leaves. Group man- 
agement component 118 manages join and leave operations, and establishes and generates messages to have key 
manager components 109 perform necessary key changes (described hereinbetow). « k a 

[0038] Key control group 117 is a virtual subgroup of participants (akin to key control group 107) defined by shared 
keying information and linked by any multteast, broadcast, or anycast channel delivering packets from group manag^ 
ment components 1 1 8 to at least the intended receivers 1 1 1 . The keying infomiation that defines key control group 1 1 7 
is held in the fiat data structure or key database in accordance with the centralized flat implementation of the present 
inventk)n In the implementation shown in FIG. lb. the physical instance of this key database is centralized in. for 
example the sender or in components physically separate from but associated with sender 121. Traffic in key control 
group 117 comprises packets containing new keying material which needs to be distributed to key management com- 

[M3ffl^ In FIG la and FIG. lb. transmissions over key control group 107 and 117 have to be received by eveiy 
participant 101 (or receiver 111), which can be achieved by (1) implementing components of any reliable mullica^ 
mechanism or (2) perfomiing retransmits on a regular basis with a limited history of key changes, resulting in a soft 
state approach The latter approach is desirable for scenarios without a return channel and is especially useful it the 
loss rate is known (e g. through bandwidth reservation) or through known good or reliable transmission channels 
Periodic retransmissbns enable a participant to catch up with key changes after being out ot touch with key control 
group 1 07 for a specified period of time. Less reliable channels require a higher retransmission rate or a longer duration 
of retransmissfon to account for dropped infomnatkjn. 

[0040] If for any reason a receiver 111 or receiving participant 101 should be unable to receive a packet in reasonable 
time the fallback solution is for the participant 101 or receiver 111 to contact group manager 108 or 118 again. This 
can klso be done using a secure unicast connection or an out-of-band channel akin to control connectcn 104 when 
there is not a return channel. 



2S 



30 



3S 



40 



4S 



so 



55 



6 



EP 0 952 718 A2 



10 



IS 



20 



[00411 FIG 2 Illustrates In block diagram form traffic distribution components witfiin each participant 1 01 including 
network interface 201. network drivers 202. and a physical communication network 207. These components are con- 
veniently implemented using available hardware and software solutions to meet the needs of a particular networx 

rowaTe traffic encryptton component 203 is the component that actually sends data. Traffic encryption component 
203 holds a symmetric traffic encryption key (TEK) that is generated by the group key management component 108 
and receded and decoded by key manager component 109 shown in FIG. 1. The traffic encryption comfxjnent 203 
uses the TEK to encrypt data that is to be sent out and deciypt data that is received. In the example of FIG. 2. ine 
traffic encryption component 203 receives network packets (e.g.. IP packets) from the transport layer 204 (wh«h in 
tum include data messages generated by participant multicast applkation 206). encrypts the entire network packet 
and adds new header information (unencrypted) to direct the packet. Traffic encryptton component 203 also receives 
network packets with encrypted paytoads from network driver component 202. decrypts the packets using the stored 
TEK and sends the decrypted packet to transport layer 204 for use by participant application 206. This encryption/ 
decryptwn can be performed using any available encryptkxi algorithm or combination of algorithms including Dtb. 
RC4 other block stream ciphers, and the like. The encryption can also happen at any other convenient level. 
r00431 An example network 207 includes a multeast backbone (MBONE) virtual transport mechanism operating on 
top of a conventional Internet protocol (IP) Intemetworlc It is contemplated, however, that the present invention may 
be usefully employed on any physical network including wide area networks, local area networks, and the like. 
r00441 In accordance with the distributed flat implementation of the present invention, admission control componen 
110 is implemented in each participant 101. In this manner, each participant 101 is able to perfomi access contro 
operations Also, each participant 101 includes a group manager component 108. More accurately, each participant 
101 is capable of implementing a portion of group manager component 108 such that multiple participants working 
cooperatK/ely implement the functionality of group manager 108. In this manner, each participant 101 is "ot burdened 
with the brge resource requirements of a centralized group manager 108. However, because any participant may 
25 initiate join and leave operations, trust in all participants is important. 

r0O4Sl The main concems with centralized approaches such as that shown in FIG. 1 b is the danger of implosion and 
the existence of a single point of failure. Hence, the implementatton shown in FIG. la offers an attractive d«tnbuted 
solution for the key management problem. In accordance with the present invention the key datable o group toy 
manager 108 is completely distributed, such that all participants 101 are created equal and no individual partjcipan 
101 has complete knowledge. Each participant 101 only holds keys matching its own ID. and the col^boration of 
multiple participants 101 is required to propagate changes to the whole group. There is no sirigle entity dedicated to 
implementing group manager 1 08. instead, every participant 101 may (but does not always need to) perfonn admission 

Sm€1 °TT)eSibuted flat implementation is resilient to network or node failures because of its inherent setf-healing 
capability However, it is somewhat more vulnerable to inside attacks because key management is distributed. Hence, 
appropriate precautions shoukJ be taken to control the risk of such attacks. The present invention offers the high re- 
sisfance to break-in attacks and thanks to its higher resilience to failures, it can be considered stronger against outs.de 
•denial-of-sen^ice" attacks than is the centralized flat solution shown in FIG. lb. 

r00471 The present invention is usefully understood in terms of five distinct stages or states «i the operation of the 
components described herein before. The states include -group creation', -group join-, "data transfer- group leave 
and -group destnjction-. These operational states are described in greater detail after descnbing the data stmctures 
of the major components in accordance with the present invention. 

r004Sl Each partcipant 101 or receiver 111 is kJentified with a unkque ID. In either implementation there is no smg e 
dedicated entity having global knowledge of the participant IDs in use. each participant ID should be generated uniquely 
in a distributed way In accordance writh the present invent ion, the participant's network address (e.g. . the concatenation 
of its IP address and port number) is used directly or in combination with a collisbn-free hash function to provide unique 
participant IDS. AttemativeV. an asynchronous transfer mode (ATM) address or any type of network dentification or 
infomiation derived from the network identification may be used as the participant ID so long as the ID generation does 

S4'^^'fiG "3 iHuiratesa simplified example of a group key manager database 300 usefulto implementa key control 
group 107 or 117 shown in FIG. la and FIG. lb. For ease of understanding, this database is illustrated as a unified 
entity, however, it shouW be understood that in accordance with the distributed flat i'^P'^'^'entaton of the pre^^^^ 
inventton database 300 is actually distributed among a plurality of participants 1 01 . The example of FIG. 3 is simplified 
in that each W-symbol long participant ID is assumed to comprise only four binaiy symbols (I.e.. W=4). 
[00501 The database 300 includes a number equal to 2.W+1 entries 400 stored in. for example, a simple tfble <teta 
stojcture One entor 401 holds the current TEK. and the other 2.W entries 400 hoW -key encryption keys (KEKs)^ 
When us ng single bits of the participant ID to designate the keys, there are two keys available corresp^ding to the 
JIovalues(0and1)that the btt can take, totally 2.WKEKsand1TEK. On the left side of FlG.3arekeysKEK1thr^^^^ 
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KEK4 corresponding to ID address bits equal to zero. On the right side of FIG. 3 are keys KEK5 through KEKB corre- 
scx^dinq to ID address bits equal to one. w^i. .«o 

S More generally. wheS mutti-bit symbols are used, each of these symbols can take any of V possible vaU^s. 
K. each entry 40ol uniquely identffied by a symbol-value pair designating a rule as to how to extract the s^ol 
,r^ tt^e ID and7he value of that symbol. totaBng to VW KEKs. In a typical apphcatKxi, the P^^.c-pan^jf 
m^h longer and not on^ single bits may be used to differentiate between the keys, but any number of brts n^y be 
Ze6 (e g groups of three or four bits). For ease of understanding, the examples use symbols consisting of a single 

?S Each participant 1 01 or receiver 111 is "aware of or 'knows' W of the keys from database ^"f "^^J 
leTs to encryprand/or decrypt messages. By 'aware of and 'knows' as used herein it is meant that the software 
rS emenTn^tf^e key managTr 109 and 119 ^dudes va^^^^ 

infomiation. 'lUe selection of whk:h W keys are known to a particular part«,pant 10 « "J^.^'^ff^^"^ "^^^ 

patteminthatpartk:ularpartlcipant'slD.Forexample,aparticipant101withadecimalpartc.pantlD=10 0.«_.ab"a^ 

M ittem of <1010» knows ttTe TEK, and KEK1. KEK6, KEK3. and KEK8. In this manner, as each participant 101 

holds a unique ID it also holds a unique combination of the keys. 

f«?3] FIG. 4 Shows the contents of an entry 400 in database 300. In both the centraliz^J flat and cl«« "^^ 
o^erlentations the keys (i.e.. the TEKandKEKs)have associated version and revisionnumbe^ 

numbers are used in operation to maintain security relationships as described bek^w.Jn the '^''^^'^^^[^^ 
ILtion the version and revision number maintenance are perfomned by the centralized group key management com- 
Donent 120 and so this component is deemed to "own" the keys. ^ ,^ ^ u ,j «. orf/.i„antin 

K in the distributed flat implementation each eniry 400 also includes an owner field that holds the parUc^ant 
S^e participant 1 01 that is designated as a 'key holder' for that key TTie owner field is not requir^ 
tetTrSplemen^bn as the centralized sender entity is the owner of all the keys. In the d.stnbuted ''"P'«'^"^''°" 
no s5e partteipant 101 is able to be the key holder or owner of more than W of the KEKs. Hence, the keV da^^f « 
in each participiTt 101 or receiver 11 1 comprises a fiat data stmcture having W+1 entries 400. A s.gnrficant d flerence 
be"2n 2T«emath,e implementattons is that in the distributed flat «T,p.ementatic^ some 
designated as the owner of one or more of the W.I keys whereas in the centralced flat ^P'^^^'^^^^J^^^^^^^^^ 
entity is the owner of the whole set of keys (i.e.. V-W+l keys), of which separate subsets compnsing W+1 keys are 

S %'a"L;Tnts Toi\hat are distinguished as 'key holders", perform some authoritative function. ^ function 
Sniy need^ to improve performance on version changes, b) is assigned naturally to the creator of me newest 
vi lion of t^fkey. and c) can be taken over at any time by any other partteipant 101 that has received a key upda e 
merge' ro^ he key holder, « that node shouW fail. In other words, no specal trust is need^ to '-^f ^ 7"^^ 
of a tey The duties of a key holder are to generate a heartbeat message distributing the key and to perfomi key 
translations. These functions are described in greater detail below. m 
S)S6] During join operattons. revision numbers of the keys to be given to the new participant 101 <^'^^^^^'l'J. 
LreinLeased by the act^,e group key management components 108 or centralized ^r-P key "^^^^^^^ 
keys are put through a one-way function implemented by group key management component 108 or ^1^,^°^^^^^^^^ 
ke^r^^glentl.mponents^09or119.Thissystem^ef,nedone-^^ 

the group key manageVl 08 (or key manager 11 8) and each participant key manager component 09 (^^^^^^ 

new keyfngrLterialtobe generated, without the needfor communicating the new keying n^^^^^^ 

to be communicated is the increased revision number. Ttie transmission of the revision number of the KEKs^ be 

lstpo^untiltheupdatedkeysareactualtyused.Thisoccursduringaleaveoperatto^ 

one-way function is the MD5 algorithm, the secure hash algorithm (SHA) or an equivalent. -^M.-Hinn 
During leaveoperations, every key known to the leaving participant 101 or recever f ' ^'"f '"^ 
thTTEK itself The changed keys need to be communicated from the active group managers 108 (or group manager 
1 8) to eS oHhe participants 101 (or receivers 111) that know one of the changed keys. Also, the vers.c^numbe- 
i tiose keys are in^easil. By periodically changing keying material and chang^g of revisKx. numbers even .n me 
absence o7pins and leaves the window of opportunity that an attacker has before perfect fon^ard secrecy « m effect 

i^T^^hecentralized flat approach.akeycontrolgroup is created when group key manag^^^^ 
lygenerating TEK and Keg's to fill entries 400 In data structure 300. Group key manager 118 announces its pubte 
kevoarameters and access control contact address ma heartbeat message. u - k 

[0059] In the distributed flat implementation, key control group creation is accomplished on an ad hoc b^s's b^^^J 
IheTe s no distinct group management component 108. The first participant 101 in the group obsen/es traffic and will 
find thrr^ -ht^eat- exists aSd start to create Ks own keys (i.e.. the TEK and W of the 2W KEKs (o-^--^.^ 
VW KEKs). Hence, the inilBl participant generates the keys it would have receded from he Sroup mar^age 118 in 
the centralized flat approach. The initial participant 101 starts a heartbeat announcing itself and the fact that rt .s key 
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holder for the keys it just generated. Each participant 101 that is a key holder perforrns a ^^a^'^'^^^f '^^'^^"'^'"^ 
out a message containing its view of the newest keys. Optionally, the heartbeat includes a short history of previous 
keys, as an automatic retransmission in case some messages were lost Each participant 101 that has recently has 
created a key. will conskier itself a key holder of the created key so long as it hokJs the newest versnn of that key 
5 When a participant received a heartbeat superseding it own (i.e. a heartbeat including a newer version ofa key erf 
which it considers itself a key holder), that participant will cease to consider itself a key hoWer of «]f' k«y;0^«7'"'« 
the distributed flat implementation reaches a stable state in which heartbeat messages produced by drffererit key 
holders are equal. This results in a small number of messages being sent out in a regular fashion, in addition to rhe 
reeking messages. The newcomer also has to verify that the admrtting node is trustworthy, if rt does not want to nsk a 
10 "man-in-the-mkldle' (or other impostor) attack. . . 

r0O6O] The heartbeat contains for each keythe key's ID (e.g., a bit-value pair describing the key's location in database 
300) version information, and revision information. In the distributed flat implementation the heartbea message also 
includes the owner ID for each key. In ear^ phases of group constructbn in the distributed flat ^^^"'^T^ZZ 
previous common key exists, multiple creations of the same key are resolved as described betow wrth respect to leave 
operations, except that a unicast connectk^n is opened between the key hoWers to establish « Pr^'°"! ^^f^^^^^^ 
fOOSIl AnynewparticipantlOl orreceiverlll intending to join the multcast group listens for the heartteat message 
produced by the initial participant 101 (distributed flat) or the sender's group key control component "8 (centrate^ 
flat) A new receiver 111 receives the address of the multicast group via a sesskjn directory and gets the heartbeat 
message broadcast by group key manager 118. The new receh/er 111 establishes a private ^^^^'J'^'^^^. 
nection with admission control component 1 20 and, H successful. receK/es a set of KEKs ^^-^^^ ^^'^^''f "fj^^^^ 
address and the TEK encrypted using the KEKs. The TEK is decrypted and the new receiver 111 can begin to decrypt 
traffic using the received keys and the connection with admissfon control component 1 20 is ctosed. 
r0O62] In the distributed flat implementation, new participants 101 will find one or more heartbeat messages. In a 
stable state there may be up to 2W (or more generally VW) different sources for the heartbeat messages in the d,^ 
tribuled flat implementation as multiple prk>r participants may be acting as key hokJers. Before reaching J^ble 
state there may be more than 2W (or more generally VW) heartbeat sources. The prospective new Part;c,pant «only 
interested in at most W of the heartbeat messages and collects a table of owners of keys which he needs, and whi^ 
are owned by different participants. All those key bits that a new participant 1 01 needs but which have not been assigned 
are created by the joining participant. . , mi ackc w 

r0O631 The joining participant then contacts one or several (a small number) of current participants 101 and asks tor 
admission to the group, at the same time publishing its public key parameters, credentials etc. Any participant sharing 
bits in the network address with the newcomer can choose to do an admission check, and if successful, may provide 
the newcomer with the current TEK and the KEKs that they share. Participants failing the admission check are desirably 
notified so they can take approprete action. The keys are sent encrypted using the keying information PJ^^^^ ^^l 
any key bitsthatthe new pa,tk:ipant cannot acquire this way, hecreatesaunicast connection totheauthorrta^^^ 

of a key for a bit (the owner or key hofcier) and asks that participant 1 01 for admission and appropriate keying ma erai 
[00641 The prior participants 101 that provide keys to the joining participant in the distributed flat implementation 
ncrease the revision number of the keys they provide and announce this change to the group in a key control rri^ge 
via key control group 107 (shown in FIG. la). The participant key manager 109 can begin to process tratfK: f ^ the 
exiting participants using the received keys. Once the connecton is set up. the unicast connection(s) e/are closed^ 
[00651 It Is contemplated that the system may be implemented such that only pror participants that are acting as 
key holders answer queries from new partcipants 101 to reduce synchronization problems. Dunng a pin the joinirig 
participant will first multicast a message on the "owners multicast group- without increasing rings. If no answer is 
received, the participant starts to grow a ring on the "participant multicast group". Alternatively, the {^"'"g particip^ 
may wait passively for a heartbeat which will contain the necessary information or listen for any senders with a parte^ 
netLklDmatchLidcontactthemfor admission infomiation. This would befoltowedbyapossibleselectionorelecti^ 

of an owner, adding an automatic liveliness test. , „r,f «ot ii<tPd 

[00661 If the newcomer had to create some keys of its own. because it uses symbol-value pairs that are not yet used 
within this group, it becomes a key holder for these new keys and so starts to heartbeat his key table. The Part^'Pant-s 
key table is a subset of key table 300 (shown in FIG. 3) having at most W+1 of the (2.W>M keys (or more generally 
(V.W)+1 ) keys . Each entry 400 in the participant's key table includes owner's addresses and version/revision numbeis 
of keys f the other key owners admit the new participant 101 , they will adapt their own key tables to show the new 
^Spant as owner oi the newly assigned key bits. In this manner, all group participants 101 will eventual^, learn 

^TI*' Verau°7paSant 101 includes admission control component 110 in the distributed flat embodiment, each 
may elect to perform local admission control, and ignore ownership of unadmitted peers. Each part^ip^ 01 
alsocan use itsownadmiss«ncontrolcomponent120toadmitthecurrentparticipants.Th« action avoKte the possibih^ 

of fooling the newcoming participant by a rran-in-the-mkJdIe style attack. 



IS 



20 



25 



30 



35 



40 



45 



SO 



9 



10 



15 



20 



2S 



30 



35 



40 



45 



SO 



55 



EP 0 952 718 A2 

r0O681 In the distributed implementation, the TEK is owned by the first group member (i.e.. the participant that gen- 
erated the TEK) unless ownership is transferred to a successor. If a key holder should stop announcing rts function 
any other participant 101 knowing that key can take over. Ownership transfer occurs automatfcally when the current 
TEK owner leaves the group, is forced from the group, becomes unreachable, or othenA/ise fails to broadcas its heart- 
beat message After a system-specified time without receiving the heartbeat one or more of the participants 1 01 will 
claim to be the new owner. If there are multiple claimants (i.e.. participants 101 that are willing to take oyer a non- 
flooding election scheme should be used to decide which participant becomes the new owner. For example, the par- 
tk:ipant 101 wtth higher priority (e.g. higher network address) wins. Any criteria can be use to «f ^ 
however, by basing the selection criteria on the partfcipants IP address, network ID. or participant ID the select^ can 
occur with minimal communication between the participants. Additionally, the replacement key holder might want to 
oerform a leave operation, discussed below, for the old key holder. ^- „ . ini 

S)6gi Tbe new owner starts Its own heartbeat, and acquires ownership of the TEK. If the missing participant 101 
comes back later, and resumes its heartbeat, the one with the lower address will again win. Although this P/«:ess .s 
described in terms of transferring ownership of the TEK. a similar procedure ^ used for transferring ^wnersh^D o, any 
KEK also. In the case of KEK transfers, however, the new owner must be a partcipant 101 that knows the KEK that 

ft^jm N^^al Sta transfer in accordance with the present inventton sent in packets 800 ha^"9 f 

Lhown in FIG. 8. Each packet 800 includes an association ID field whfch gives the ID of the partic^ ^ 

the data packet 800. Each packet 800 also includes a key version field and a key revision field. The KEK reviswn 

number may be a single bit which is set (i.e.. placed in a one level) by join operations and reset after a leave operat^ 

has caused this key to be replaced with a new version. Additional headers which may comprise one or more header 

fields used in the traffic dtetribution component are also provided. Ihe encrypted payload ^P^^^^^^"^"^ .^P: 

cn^pted IP packet (e.g.. a SKIP packet). As each packet is received by a recelvmg P«'^''='P^»J^°J:;'^t Pf.^^^^^^^^^ 

can detectVey revision changes and use the one-way function to generate the same revised key. 

also indicate version changes which involve new keys, but the new key Is provkJed In a separate update or ree^^S 

message described hereinbelow. The participant 101 can also request a message be resent if a versran update was 

missed due to damaged or dropped packets which are typteal in an Internet applicattoa 

[0071] Traffic encryptton/decryption is accomplished in the participants 101 by the traffic encryp^on comPO"«"^ ^Oa 
Srticlpants 101 detect an Increase in the key revisk^n number and put the revised key through ^^^'^^V*""^^" 
to generate the new key and start enco^pting/decrypting data with the new key. Participants 101 put their stored traffic 
encryption key through the one-way function. This generates the new TEK" (where the prime designation indicates a 
new version) in each participants database. Once the new key update occurs, normal operation continues. In th« 
ZnerTrt ipams 1 o'l ne^b' communicate that a key has been revised in order for all participants 1 01 to upda^ 
Zu keys to the new key. It is desirable that participants 101 keep prevtous (i.e.. outdated keys for a short^^ m^ 
defined time (e.g.. one to three minutes) to handle cases where the sending participant 101 has not yet received the 

"Sg'^S operation the access control component 110 in one or more participants 101 inforrns the group 
Ly rinagement components in the other participants 101 that one or more partteipants 101 are '^>''"9 ^J^^a^ 
that they are no longer authorized to receive group multicast messages. TTie access control component 11 0 may initiate 
or throw out these participants 101 or simply may have detected that the partteipants thernselves have lett. 
So731 If one participant 101 (an -excluder') decides to throw out another partteipant 101 the excluder chooses a 
new TEK- and encrypts it with every KEK encryption key that it knows it does not share with the participant 101 that 
is to be thrown out. The KEKs that are known to the leaving participant are thrown out, leaving a set of rernayiing KEKS 
thlCLwnon^torema^ingparticipantslOl.TheexcluderassignsnewKEKsf^ 

KEKS which are encrypted using the corresponding old KEK and the new TEK. The excluder then J^V 
owner for the newly assigned KEKs. Ihe excluder participant populates a table wrth this information and sends it to 
the group. Alternatively, the function of assigning new KEKs can be left to another key ovmst entity. Eve-y pa^c^ant 
that is able to understand the new TEK decrypts it. begins to use it. supplements the table wrth new KEKs wh^^h rt 
holds but whffih are not yet present in the table, and rebroadcasts the table. 

[00741 If two participants 101 try to assign a new KEK to one slot at the same time (both using the same new incr^ 
mented verskxi number), the two KEKs are combined into one by the merging schemes discussed 9;«^»«; ' 
below in reference to FIG. 5 through FIG. 6 illustrate this feature of the present invention in greater detail. Table i 
J!Z ^ eSiple table prepared by an excluder participant with 1D=9 (binary 1 001 ) wants to throw out a partK^ipant 
With ID=10 (binary 1010): 

Table 1 



I UnusableAJnknown | new TEK enciypted in old KEKS | ID address bitT| 
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Table 1 (continued) 
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new TEK encrypted in old KEK2 


Unusable/Unknown 


ID address bit 1 


Unusable 


Unknown 


ID address bit 2 


Unknown 


Unusable 


ID address bit 3 



Where the slots marked 'Unusable" are known by participant 101 with I D= 10 therefore the KEKs stored in these slots 
may not be used to encrypt the new TEK (indicated as TEK'). and need to be replaced. The slots marked 'Unknown- 
are not known by participant 101 with ID=9. Slots that are neither unusable nor unknown can be used to convey the 
new TEK' encrypted with the slot's okJ KEK. Those slots that are only marked unusable will be filled with new keg's, 
encrypted in the new TEK' and the old KEK. The table sent out by the excluder participant looks like: 

Table 2 



Unusable/Unknown 


new TEK in KEKS 


ID address brt 0 


New TEK encrypted in old KEK2 


Unusable/Unknown.;^ 


ID address bit 1 


New KEK3 encrypted in oki KEKSTTEK' 


Unknown 


ID address brt 2 


Unknown 


New KEKB encrypted in old KEK8/TEK' 


ID address bit 3 



The participants 101 with ID=-xx10' where represents an unspecified value (i.e.. participants 2.6.10.14) cannot 
understand this message, and need to wait tor a fuller table, or have to contact one of the other participants 101 directly 
if they do not get the update message in time (e.g. the sender of this message, owner of a key bit or a recent contnbutor 
to traffic in the group). The participant 101 with ID=10 will never be able to understand the message, and assuming 
consistent admission control mechanisms, he will also not be able to acquire the new TEK from other participants 1 01 . 
He will stay excluded, which is the goal of the leave process. 

[0075] It is best that changes to the admission control shoukJ be synchronized with the key update message. Oth- 
erwise, an excluded participant 101 could try to come back in to the multk^ast group until the admissron control com- 
ponent is updated. It is possible to do this in conjunction wrth the key change, such that no exploitable inconsistencies 
exist. Also everyone joining later needs an up-toKlate blacklist indicating excluded participants (or a whitelist indicated 
currently included participants) . 

[0076] As an example, participant 101 with ID=1 (i.e.. binary 0001) receives the message in table 2 and completes 
it as far as possible to generate Table 3 shown below, before sending it out again. 

Table 3 



Unusable/Unknown 


new TEK in KEKS 


ID address bit 0 


New TEK encrypted in old KEK2 


Unusable/Unknown 


ID address bit 1 


New KEK3 encrypted in old KEKaTEK' 


Unknown 


ID address bit 2 


New TEK encrypted in KEK4 


New KEKB encrypted in old KEK8/TEK' 


ID address bit 3 



[0077] Next, a participant 101 with ID=6 can fill in its solutions. If participant ID=2 would at the same time assign a 
new KEK1 and KEK6. the new KEK6 of participant ID=2 would win. because 2 is the bwer network address. The 
resulting table 4 is complete. 

Table 4 



New KEK1 encrypted in old KEK1/TEK* 


new TEK in KEKS 


IDadress bitO 


New TEK encrypted in old KEK2 


New KEK6 encrypted in old KEK6/TEK' 


ID adress bit 1 


New KEK3 encrypted in old KEK3/TEK' 


New KEK7 encrypted in old KEK7/TEK' 


ID adress bit 2 


New TEK encrypted in old KEK4 


New KEK6 encrypted in old KEKB/TEK* 


IDadress bit 3 



[0078] If two participants generate common and separate KEKs at the same time (e.g. participant ID=2 generates 
KEK1 . KEK6 and KEK3, and participant I D=1 4 generates KEK1 . KEK6 and KEKS) others wouW use the keys provided 
by the tower network address separately considered for each key (i.e. , selected on a key-by-key basis). In the particular 
example this would result in KEK1. KEK6 and KEK3 from participant 2, and KEKB from participant 14. 
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[0079] Participants 1 01 that after a specified time still cJo not find a TEK' encrypted in a KEK they can read, establish 
a secured unicast to one of the participants, acquire the TEK". expand the table and then broadcast the expanded 
table This takes care of the situation where two distinct groups of participants 1 01 cannot comnnunicate over multicast 
because they do not share any key encryption keys that they do not also share with the participant that is to be thrown 



out. 



[0080] Groups are destroyed when all of the participants cease to exists in which case all secrets (the TEK and all 
KEKs) are discarded by each participants 101. 

[0081] It is useful to understand a number of concepts which help to explain how the system in accordance with the 
present inventbn works with no centralized control with a number of partrcipants 101 performing operations at the 

10 same time. These concepts are taken up in turn betow: 

Key Merging Since multiple participants may create new keys at the same time, each has to include its own 
creator ID to assure uniqueness. Additionally, each key holder has to include infomnation indicating upon which key 
(version, revision, version creator) the new key is based, since this also is the key it is encrypted with. This allows the 
participants to implicitly (i.e. without sending additional messages) agree on a common key and also be able to under- 

15 stand any traffic that was encrypted using both the individual and the merged keys. Three typical merge scenanos are 
shown in FIG. 5-FIG. 7 and discussed below. In FIG. 5 through FIG. 7 the key message is indicated in parentheses 
by components (version#, revisbn#, version creator ID). 

[0082] A first case in which multiple new revisions are received by a participant is shown in FIG. 5 where key holder 
501 generates a key with a revision increase to participant 502 and 503. Participant 504 receives the key revision 
20 message from both participant 502 and participant 503 and can readily determine that there is no conflict since the 
key is the same in each message. In this case, no action is needed to get the new key because a revision increase is 
well-specified (i.e., non -ambiguous) and repeatabie. 

[0083] A second case in whch multiple new versions are received by a participant is shown in FIG. 6. In this case, 
key holder 602 and key holder 603 have created version increases of the key from key holder 601 . Participant 604 can 
25 see that the same version has been created by several key holders, and can combine these keys into a single new 
key which can be readily calculated from the base keys (e.g. using exclusive-or). The merged key's version creator ID 
will be the set of ID-tuples. Any key holder of a base key shouW consider itself as a key holder of the merged key in 
the first step until it is superseded (as described hereinbelow). 

[00S4] In a third case shown in FIG. 7, a new versbns is created by key holder 702 while keyholder 703 generates 
30 a new revision. Any participant 704 seeing a revision increase on a key that has been superseded by a version increase, 
should increase the revision of the new merged key accordingly to assure perfect forward secrecy. The key holder for 
the new key may re-encrypt the new key with the new revision of its base key, to simplify operation for the newcomer 
that caused the revision increase. u- - t 

[0085] A key holder stops performing a heart-beat, if its message is superseded. A message with key K is to oe 
considered superseded, if any of the foltowing keys are being announced: (a) a new revision, (b) a new version, which 
bases on K or any key superseding it, (c) a merged key which includes K, or (d) K is a merged key and it is being 
announced by a contributor to that key which has higher prksrity (e.g. higher network address). 
[0086] Although the invention has been described and illustrated with a certain degree of particularity, it is understood 
that the present disctosure has been made only by way of example, and that numerous changes in the combination 
and arrangement of parts can be resorted to by those skilled in the art without departing from the spirit and scope of 
the invention as hereinafter claimed. Specifically, it is contemplated that forty-eight symbols with each symbol com- 
prising a two bit value could be used that directly nr^ap to an IP address and port number of an application thereby 
uniquely identifying the application in the network. In this case, the second part of the table (e.g.. 64 symbols with 16 
values each) encode keys that can be used to counter colluding participants. Normal join and leave operations can be 
45 performed on the 48 symbols which have high connectivity in the participant network, and whenever colluding enemies 
need to be thrown out. the other 64 symbols are available to be used. Colluding enemies would then have to be m the 
number of at least 2« (e.g. 2^6 in the specific example) to blank out all participants. One can combine different tables 
with different symbol spaces to achieve a number of properties of the resulting distributed system. These and similar 
modifications are readily implemented in accordance with the basic teachings of the present invention and are consid- 
50 ered equivalents. 



Claims 

55 1, A system for secure muttk:ast comprising: 

a number (N) of participant entities each of which run on a participant computer system, the participant entities 
having a multicast application running thereon; 
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a traffic distribution component coupled to each of the participant entities, the traffic distribution component 
supporting multiple receiver communication; 

a participant key management component within each participant entity, the participant key management com- 
ponent holding a first key that is shared with all of the number (N) of participant entities, and a set of second 
keys each of which is shared with a subset of the participating entities; and 

a group key management component having a flat key storage data stmcture storing the first key and the 
second keys, wherein each second key is stored in an entry in the data structure that is uniquely associated 
with a subset of the participants. 

2. The system of claim 1 wherein the group key nr^nagement component is implemented in a plurality of the partic- 
ipants and the group key management components of the plurality of participants cooperatively define the flat key 
storage data structure as a distributed data structure storing second keys of all the participants. 

3. The system of claim 2 wherein the group key management component is implemented in a centralised fashion 
and associated with only one participant 

4. The system of claim 2 wherein the second keys are associated with an ID identifying one of the participants that 
owns that second key. 

5. The system of claim 2 wherein the first key is associated with an ID identifying one of the participants that owns 
the first key. 

6. The system of claim 1 wherein the first key is marked with a revision tag and the system further comprises: 

a one-way function generator operating in the group key management component and each participant key 
management component, wherein each one-way function generator accept the first key as input and implements 
the same one-way functbn on the first key to generate a new revision of the first key. 

7. The system of claim 1 wherein each second key is marked with a revision tag and the system further comprises: 

a one-way function generator operating in the group key management component and each participant key 
management component, wherein each one-way function generator accept each second key as input and imple- 
ments the same one-way function on the second key to generate a new revision of the first key 

8. The system of claim 1 further comprising: 

a random key generator in the group key management component of at least one participant associated with 
the group key management component, wherein the group key management component assigns the first and 
second keys as needed and designates the participant assigning a specific key as a keyhokJer for the assigned key. 

9. The system of claim 8 further comprising: 

a heartbeat message generator within each keyhokJer generating a heartbeat message; and 

an admission control component in each keyholder coupled to the traffic distributran component and responsive 

to receive responses to the heartbeat message to selectively admit partcipants. 

10. The system of claim 1 wherein each participant is kientified by a W-symbol wide !D wherein each symbol can take 
on a number (V) of values, wherein the value V may be different for each for the W symbols and each participant 
holds W second keys, 

11. The system of claim 10 wherein V«W second keys are distributed among all of the participant entities In the entire 
system. 

12. The system of claim 1 wherein each participant is identified by a W-symbol wide ID wherein each symbol can take 
on a number (V) values and each key data structure comprises a (V»W)-entry database. 

13. The system of claim 1 wherein each of the participants lacks knowledge of the identity of at least some of the other 
partk:ipants. 

14. A secure multicast participant system running on a computer system that is coupled to a multicast enabled traffic 
distribution network, the secure multicast participant system comprising: 
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a traffic distribution component coupled to interface with the network; 

an admission control component coupled to receive and send messages on the traffic distribution component; 
a heartbeat message detector in the admission control component for detecting a heartbeat message identi- 
fying an address of a key owner and keys owned by that key owner; 

a group key management component comprising a fiat database having a plurality of entries, wherein each 
entry includes a key field holding a key value and an associated owner fieW holding an I D of an owner of the key; 
a first key stored in an entry of the database wherein the first key is shared with a group of extemal participants 
and 

a set of second keys each of which is shared with a subgroup of the group of extemal participants; 

a traffic encryption/decryption component coupled to receive encrypted data packets from the traffic distribution 

component and decrypt the received data packets using the first and second keys; 

a transport component coupled to the traffic encryption/decryption component to receive the decrypted data 
packets and generate application data; and 

a receiver multicast application coupled to the transport component to receive the application data and provide 
receiver-side multicast services using the received application data. 

15. A secure multicast group comprising: 

a group of participants each having a unique network ID wherein at least one of the participants acts as a 
sender and at least one of the participants acts as a receiver, 

a participant key manager in each of the participants having a data structure holding a first key that is shared 
with all of the participants and a set of second keys; 

a group key manager having a data structure holding the first key and all of the second keys, wherein none 
of the data structures include data representing the unique network ID of all of the participants. 

16. The secure multicast group of claim 15 wherein the network ID of each participant is used to select the set of 
second keys held by that participant. 

1 7. The secure mu tticast group of claim 1 6 wherein the network ID of each participant is determined from an I P address 
of the participant 

18. A method for conducting secure multicast communication over an unsecure communication network with a group 
of participants, the method comprising the computer implemented steps of: 

creating a data structure within each participant, the data structure having a transmission encryption key (TEK) 
entry for storing a TEK and a set of entries for storing a set of key encryption keys (KEKs); 
causing one of the participants to generate the TEK and designating that participant as a TEK key holder; 
causing at least one of the participants to generate the KEKs and designating each participant that generates 
a KEK as the keyholder for the KEK that was generated; 

distributing a set of KEKs from each KEK keyholder to each of the participants such that each participant can 
only receive a unique set of KEKs; 

storing the unique set of KEKs in the set of entries of the data structure within each participant; 

for each participant, encrypting the TEK using the uniqueset of KEKs distributed to that participant; distributing 

the encrypted TEKs from the TEK keyholder to all of the participants; 

in each participant, decrypting one of the encrypted TEKs using the unique set of KEKs stored in the partici- 
pant's data structure; 

storing the decrypted TEK in the TEK entry of each participant; 
generating a message within one of the participants; 

encrypting the message using the TEK held by the participant generating the message; and 
distributing the message to all of the participants; and 

decrypting the message in each of the participants that hold a TEK matching the TEK of the participant gen- 
erating the message. 

19. A computer program product comprising: 

a computer usable medium having computer readable code embodied therein for conducting secure multicast 
communication over an unsecure communication network with a group of participants operating on participant 
computer systems, the computer program product comprising: 
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computer program devices operating in the participant computer systems and configured to cause the partic- 
ipant computer to creating a data having a transmission encryption key (TEK) entry tor storing a TEK and a 
set of entries for storing a set of key encryption keys (KEKs); 

computer program devices configured to cause the at least one participant computer system to generate the 
TEK and designating that participant as a TEK keyholder; 

computer program devices configured to cause the at least one of the participant to generate the KEKs and 
designating each participant that generates a KEK as the keyhoWer for the KEK that was generated; 
computer program devices configured to cause the participant computer system to distribute a set of KEKs 
from each KEK keyholder to each of the participants such that each participant can only receive a unique 
number of KEKs; 

computer program devices configured to cause the participant computer system to store the unique set of 
KEKs in the set of entries of the data structure within each participant; 

computer program devices operating in each in participant computer system configured to cause the participant 
computer system to encrypt the TEK using the unique set of KEKs distributed to that participant; 
computer program devices configured to cause the TEK keyholder to distribute the encrypted TEKs to all of 
the participants; 

computer program devices configured to cause each participant computer system to decrypt one of the en- 
crypted TEKs using the unique set of KEKs stored in the participanrs data structure; 
computer program devices configured to cause the participant computer system to store the decrypted TEK 
in the TEK entry; 

computer program devices configured to cause the participant computer system to generate a message within 
one of the participants; 

computer program devices configured to cause the participant computer system to encrypt the message using 
the TEK held by the participant generating the message; 

computer program devices configured to cause the participant computer system to distribute the message to 
all of the participants; and 

computer program devices configured to cause the participant computer system to decrypt the message in 
each of the participants that hold a TEK matching the TEK of the participant generating the message. 

20. A computer data signal embodied in a carrier wave for conducting secure multicast communication over an unse- 
cure communication network with a group of participants operating on participant computer systems, the computer 
data signal comprising: 

a first code portion comprising code configured to cause the participant computer to creating a data having a 
transmission encryption key (TEK) entry for storing a TEK and a set of entries for storing a set of key encryption 
keys (KEKs); 

a second code portion comprising code configured to cause the at least one partrcipant computer system to 
generate the TEK and designating that participant as a TEK keyholder, 

a third code portion comprising code configured to cause the at least one of the participant to generate the 
KEKs and designating each partk:ipant that generates a KEK as the keyholder for the KEK that was generated; 
a fourth code portion comprising code configured to cause the participant computer system to distribute a set 
of KEKs from each KEK keyholder to each of the participants such that each participant can only receive a 
unique set of KEKs; 

a fifth code portion comprising code configured to cause the partcipant computer system to store the unk^ue 
set of KEKs in the set of entries of the data structure within each participant; 

a sixth code portion comprising code configured to cause the participant computer system to encrypt the TEK 
using the unique set of KEKs distributed to that partk;ipant; 

a seventh code portion comprising code configured to cause the TEK keyholder to distribute the encrypted 
TEKs to all of the participants; 

a eighth code portion comprising code configured to cause each partk;ipant computer system to decrypt one 
of the encrypted TEKs using the unique set of KEKs stored in the participant's data structure; 
a ninth code portion comprising code configured to cause the participant computer system to store the de- 
crypted TEK in the TEK entry; 

a tenth code portion comprising code configured to cause the participant computer system to generate a 
message within one of the participants; 

a eleventh code portion comprising code configured to cause the participant computer system to encrypt the 
message using the TEK held by the participant generating the message; 

a twelfth code portion comprising code configured to cause the participant computer system to distribute the 



15 



EP 0 952 718 A2 



message to all of the participants; and 

a thirteenth code portion comprising code configured to cause the participant computer system to decrypt the 
message in each of the participants that hold a TEK matching the TEK of the participant generating the mes- 
sage. 

21. A method for rr^aging encryption keys in a secure multicast group having a plurality of participants, the method 
comprising the steps of: 

creating a first encryption key in a first one of the participants, the first encryption key being associated with 
a unque subgroup of the participants; k • 

independently creating a second encryption key in another of the participants, the second encryption key being 
associated with the same unique subgroup of the participants as was the first encryptbn key; and 
combining the first and second keys to generate a single third encryption key wherein the third encryption key 
is associated with the same unique subgroup of the participants and supersedes the first and second encryption 
keys, 

22. The method of claim 21 wherein the step of combining is initiated.and completed with only unidirectional commu- 
nication between the participants. 

23. A computer program product directly loadable into the intemal memory of a computer comprising computer program 
devices or softvrare code portions for performing the steps of claim 21 or 22. 
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